home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 18527 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: ix.netcom.com!news
  2. From: Bradd W. Szonye <bradds@ix.netcom.com>
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 20 Apr 1996 16:15:27 GMT
  6. Organization: Netcom
  7. Message-ID: <01bb2ed5.084d0e40$65c2b7c7@Zany.localhost>
  8. References: <JSA.96Feb16135027@organon.com> <829194658snz@tsys.demon.co.uk> <DppsHq.1Ar@world.std.com> <01bb2dcf.e0201620$c6c2b7c7@Zany.localhost> <Dq4vpD.161@world.std.com>
  9. NNTP-Posting-Host: det-mi3-05.ix.netcom.com
  10. X-NETCOM-Date: Sat Apr 20 11:15:27 AM CDT 1996
  11. X-Newsreader: Microsoft Internet News
  12.  
  13.  
  14. On Friday, April 19, 1996, Robert A Duff wrote...
  15. > In article <01bb2dcf.e0201620$c6c2b7c7@Zany.localhost>,
  16. > Bradd W. Szonye  <bradds@ix.netcom.com> wrote:
  17. > >Pardon me if this sounds silly, but...
  18. > >You shouldn't have to rely on the documentation to make up for a lack
  19. of
  20. > >common sense.
  21. > 
  22. > Well, sorry, but it *does* sound pretty silly, to me.  Anybody who's
  23. > been around computer software for a while knows pretty well that
  24. > predicting what software does from some vague notion of "common sense"
  25. > is impossible.
  26. > 
  27. > For example, common sense might tell you that function arguments are
  28. > evaluated from left to right.  Not true in C, not true in Ada, not true
  29. > in C++ (there, I made it relevant to all these newsgroups, in case
  30. > anyone's still listening ;-) ).  These languages all go *against* common
  31. > sense (for obscure efficiency reasons, of course).  In this case, if you
  32. > rely on common sense, instead of reading the language standard, you'll
  33. > get into deep trouble.
  34. > 
  35. > - Bob
  36.  
  37. I don't let documents substitute for common sense. That doesn't mean I
  38. *ignore* the documentation; that would non-sensical too. Part of common
  39. sense is experience. Experience tells you that arguments get pushed (not
  40. evaluated) right-to-left. Experience tells you you can't count on what
  41. order C evaluates function arguments at all. Experience tells you that if
  42. you claim that a buffer is 1000 bytes long, it should be 1000 bytes long,
  43. even if the standard *explicitly* says that it's okay to do otherwise
  44. under certain circumstances.
  45.  
  46. In general, you shouldn't use every nitpicky detail of what is and isn't
  47. legal according to the standard. Not all compilers are conformant, even if
  48. they claim to be. Compiler vendors make mistakes too, and frequently your
  49. only guarantee that a compiler is 100% conformant is the vendor's
  50. assurance that it is.
  51.  
  52. I know programmers who will look up (or have memorized) the operator
  53. precedence rules in C. These programmers will always use the minimal
  54. number of parentheses in an expression because they know the rules
  55. precisely. Not everyone does; maintenance programmers in particular tend
  56. to be junior programmers who don't know all the rules. A maintenance
  57. programmer is likely to "fix" something that looks wrong, even if it
  58. isn't. And a maintenance programmer is likely to misinterpret some subtle
  59. detail of a standard that the original programmer had to look up in the
  60. first place.
  61.  
  62. My personal rule: if you have to look it up to make sure you're absolutely
  63. right, your code may not be maintainable or portable. If you can do it
  64. without looking it up; if it's absolutely as clear as the nose on your
  65. face, then it's okay. For more on this, read "Writing Solid Code" by Steve
  66. Maguire (Microsoft Press).
  67.  
  68.  
  69.